The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: afercia <[email protected]>
Co-authored-by: mirka <[email protected]>
Co-authored-by: ciampo <[email protected]>
Co-authored-by: t-hamano <[email protected]>
Co-authored-by: tyxla <[email protected]>
Co-authored-by: jameskoster <[email protected]>
Co-authored-by: richtabor <[email protected]>
Co-authored-by: MaggieCabrera <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: -34 B (0%)

Total Size: 1.78 MB

_{compressed-size-action}

@WordPress/gutenberg-components do the inputs on the ToolsPanel story need to be updated to use __next40pxDefaultSize?

cc @mirka and @WordPress/gutenberg-design who have recently discussed this in #64520 (comment)

Remove the icons.

Personally, I don't have a strong opinion on keeping the icons. If the label is clear, I think we can do without them.

It's also worth noting that in a separate issue, the current labels were reported to be confusing (#43468).

Or, if we're stacking vertically anyway, there's plenty of horizontal space, so moving the icons to the prefix might be an option.

Global Styles:

Block Layout:

However, we think we should take into consideration the points mentioned in this comment:

There is hint text below it that applies to both controls, which may be harder to visually grasp when broken up into two rows.

Or, if we're stacking vertically anyway, there's plenty of horizontal space, so moving the icons to the prefix might be an option.

That's an option to consider. However, to me, wherever we try to move the icons they will look like clickable icon buttons anyways because the editor already uses patterns with clickable icon buttons in several spots around inputs (which isn't great anyways IMHO).

To me, the simplest option to make this UI clearer, consistent, and more predictable is to just remove the icons.

@WordPress/gutenberg-components do the inputs on the ToolsPanel story need to be updated to use __next40pxDefaultSize?

I think @mirka didn't opt for adding the __next40pxDefaultSize prop to the UnitControl in stories (including in UnitControl's own stories) because it's technically not the default yet, so defaulting the stories to that can create confusion. The large size will be the default in a future version, but not just yet.

However, we think we should take into consideration the points mentioned in #64520 (comment):

I reckon it may actually be beneficial for each input to have its own help text.

I will creeate a separate issue to consider to rename the 'None' setting, as it is actually the 'content width'.

A good one to discuss separately, but I wonder if "Default" might be a better name... I find "Content" a bit ambiguous. Most blocks contain content, but they can all have different widths.

wherever we try to move the icons they will look like clickable icon buttons anyways because the editor already uses patterns with clickable icon buttons in several spots around inputs (which isn't great anyways IMHO)

We need to write detailed guidelines to clarify decorative icon usage. Icons as internal prefixes that serve as (additional) visual labels is a fairly established convention, as is internal icon suffixes that serve as interactive elements, some examples:

As long as we're consistent, it could work imo. Perhaps this could be added to Storybook?

To me, the simplest option to make this UI clearer, consistent, and more predictable is to just remove the icons.

Then you loose the correlation between the wide and content visual queues in the block toolbar.

I'm all for simplifying, but this makes the content/width width input fields lack context (important context). I'd consider this a regression.

Before	After

I'd like to approach changes with more accountability for the user-experience of the elements in focus.

For example, instead of removing icons and stacking the fields, looking at how this plays into the greater Layout and Dimensions panels. Otherwise, we keep pushing ad-hoc changes that make the greater experience worse.

If there's not a clear experience-forward approach, we start there—not on the other end, making focused changes without accounting for the relative user-experience.

A good one to discuss separately, but I wonder if "Default" might be a better name...

@jameskoster Yeah, I considered to rename it to 'Default' but then reverted. The concept of content_width has been used for ages in WordPress but that is for theme developers. It's certainly not the best terminology to use for users. I'd also like to remind that the current panel to reset the setting calls it 'Content size', which is even more confusing for users. However, I think considering the renaming should go in a separate issue, see #64906

We need to write detailed guidelines to clarify decorative icon usage. Icons as internal prefixes that serve as (additional) visual labels is a fairly established convention,

I just disagree on this specific usage of decorative icon. We need to distinguish different cases. For example:

• In a menu, using both an icon and a visible text label is the best of both worlds, as it provides visual affordance and clear understandable text.
• In an UI where there is a mix of icon buttons that are clickable and icons that are only decorative, the decorative icons are totally confusing especially when placed by using the same pattern of the icon buttons.

Consider the following screenthos:

In the same panel there's a total of 7 icons. Visually, all of them are placed after a control or a visual label. They look like they have the same functionality. As a user, I would expect all these icons to work the same way.

But no.

Only 5 of them are clickable icon buttons (the ones highlighted with a green circle).
The other two ones aren't clickable (the ones highlighted with a red circle).

To be fair, this is less than ideal. It's extremely confusing and I would say not a great design pattern.

Actually, I did try to click those icons. I've been fooled by the look of these icons, more than once.

I'm not sure this pattern contributes to make the user experience better in any way.

A completely different case is the example you provided, where icons are used in a complex form within the input fields. Ideally, meaningful label text should be enough to identify what an input field is about. I do recognize in very limited cases an icon can further help e.g. the lens in a search field.
The calendar icon for a date is usually clickable as it usually opens a date picker so it's not decorative, it's a functional button.
To me, the link and phone icon are just unnecessary and confusing.

Lastly, the vertical stacking is necessary because the labels need to be more meaningful. The current labels are less than ideal. The new ones are cleared but also longer. when translated in other languages, they may be even longer. As such, the two columns layout is just not appropriate for such inputs. We've had other cases already where a two columns layout was used without taking into consideration the larity of the labels and translations. I would argue that's not a good design.

Content comes first. Clarity of controls labels and functionality come first. The layout should be crafted around the content, not the other way around where most designs in the editor try to 'squeeze' or truncate content just to make it fit into the design.

I'm all for establishing guidelines but those should be based on these basic principles. Design around the content.

Overall, I think this PR is an improvement as it removes ambiguity and potential source of confusion.

I'm all for simplifying, but this makes the content/width width input fields lack context (important context).

I don't think icons establish a clear context for all users. They may help some users. Instead, labels and descriptions should provide context. I do agree both labels and descriptions should be improved as these settings are really unclear for users.

One more thing I haven't mentioned yet: the current icon for the 'Content' input width is the wrong one. If the desire to visually associate these inputs with the settings in the block toolbar is valid, we should at least use the correct icon. Screenshot:

Even if I personally disagree with the usage of decorative icons within input fields, and because it's Friday 🥳 , in the last commit I'm trying to use the icons in the inputs prefix. I also removed the width set on the inputs as we shouldn't use arbitrary widths. The inputs are now full width.

Screenshot:

• Left: the Styles > layout panel.
• Right: The Group block settings panel.

My personal opinion: it's better compared to the current UI. Still, the icons within the inputs may look clickable for users and be potentially confusing.

Generally I feel this is a step in the right direction. The labels are clearer, and aligned between control + toolspanel. I appreciate that the icon placement follows a more standard convention.

Separate rows is a tricky one... it does seem a shame to split them when they're so close to fitting on one row. But ultimately my feeling on this subject is that the layout should be governed by a different component—something like the Settings form layout designs we've been exploring in https://github.com/WordPress/gutenberg/issues/63624—rather than forced to work in this one instance via ad hoc styles / overrides. Clearly that is a separate, much larger discussion, and for that reason I don't consider separate rows to be a deal breaker in the short term.

It would be good to adjust the spacing between the rows so that it is consistent across the block inspector and the Layout panel in global styles.

Shouldn't the help text be consistent as well, and potentially polished a bit?

... when they're so close to fitting on one row.

@jameskoster they're not. They are in English. WordPress is translated in many languages though. Design should always take into account that many translations have strings that are way longer. A two columns layout inevitably breaks in many languages e.g. german, Italian, Spanish and many others.

I'd really love the design team to always provide mockups and designs with examples of at least 2-3 languages that are known to be the ones with longer translations.

Re: tweaking descriptions etc. I'd totally agree but prefer to split that in a separate PR. See #64842 (comment)

Separate rows is a tricky one... it does seem a shame to split them when they're so close to fitting on one row. But ultimately my feeling on this subject is that the layout should be governed by a different component—something like the Settings form layout designs we've been exploring in https://github.com/WordPress/gutenberg/issues/63624—rather than forced to work in this one instance via ad hoc styles / overrides. Clearly that is a separate, much larger discussion, and for that reason I don't consider separate rows to be a deal breaker in the short term.

I disagree here.

This doesn't seem like a meaningful step forward to warrant a change.

I'd rather think of layout as a holistic control set than ad-hoc changes that likely further confuse users. Otherwise we'll keep shifting the UI around, making the experience less familiar with every change.

I'd rather think of layout as a holistic control set than ad-hoc changes

Rather, I'd argue the current UI is an ad-hoc implementation. Those two icons aren't part of the base component. They're an ad-hoc implementation that only contributes to make the UI inconsistend and confusing.

This pattern is clearly problematic because those icons look clickable. I'd strongly encourage everyone to prioritize simplicity and clarity of the UI. Icons on the right of an input field are already a pattern in the editor and they are meant for icon buttons i.e. for interactive controls. In no case icons that are non-clickable and only have 'visual labeling' purposes should ever be placed in that spot.

It would be good to adjust the spacing between the rows so that it is consistent across the block inspector and the Layout panel in global styles.

The last commit tries to make the vertical spacing more consistent between the two editors. Screenshot:

• Left: Styles panel
• Right: Group block settings panel

Re: labels and help text / descriptions: I'd totally agree they should be improved. I'd prefer to do that in the context of #64906

I'd rather think of layout as a holistic control set

Then we should design a pattern for that purpose, based on the system fundamentals and established conventions. One that will elegantly adapt to different environments.

Thinking further down the road, if/when support for additional custom widths is available, ItemGroup may be a suitable component to use here.

But obviously this needs a dedicated exploration.

ItemGroup may be a suitable component to use here.

If screen estate was a concern, we could also switch to a icon-based ToggleGroupControl, or a CustomSelectControl

If there's not a clear experience-forward approach, we start there—not on the other end, making focused changes without accounting for the relative user-experience.

My comment still stands.

This isn't an improvement in user experience, but it is a change—one not worth the change. It's clear this isn't an ideal state of this UI/X.